這幾年 AI 寫 Code 的能力進步得很快
以前開發一個功能，可能要自己找檔案、理解資料流、查文件、寫 Code、處理錯誤，再慢慢補 Test，現在把需求交給 Coding Agent，它可能幾分鐘內就能找到相關程式碼，甚至直接完成修改

看起來 Android Engineer 好像可以少學很多東西了
但實際開始用 AI 寫 Code 之後，我反而有另一種感覺：

AI 寫得越快，我越需要知道它為什麼這樣寫

AI 寫得出來，不代表我知道它寫得對不對

現在 AI 已經可以幫忙產生 Compose UI、ViewModel、Mapper、Unit Test，甚至分析一個修改可能影響哪些程式碼，但「可以產生 Code」跟「這是一個好的修改」其實是兩回事

例如 AI 幫我新增一個 UseCase，它可能可以 Build，也符合常見的 Architecture，但這個 UseCase 在現在的需求裡真的有存在的必要嗎？

又或者看到 StateFlow、SharedFlow、viewModelScope.launch，如果我的理解只是「專案本來就這樣寫」，好像也不太夠

我希望自己可以慢慢回答這些問題：

• 為什麼這是 State，而另一個是 Effect？
• 為什麼這裡需要 Coroutine？
• 為什麼需要 Mapper 或 UseCase？
• 如果不這樣寫會發生什麼？
• 有沒有更簡單，但一樣好維護的做法？

這也是我想做這次 30 天挑戰的原因

我想做的不是「讓 AI 幫我寫一個 App」

這 30 天比起單純讓 AI 完成一個 App，我更想研究實際開發中會遇到的問題

例如 Repository 很大，這次需求到底會改到哪些地方？Bug 出現在畫面上，真正的問題是在 State、ViewModel、Mapper，還是 API Request？

還有一件我很想試的事：

如果我只提供業務需求，AI 能不能先釐清必要的問題，再產出符合現有 Architecture、可讀、好維護，而且不過度設計的 Code？

所以目前想慢慢建立一套自己的 Android AI Development Workflow：

Requirement / Bug
        ↓
Analyze Change
        ↓
Clarify Requirement
        ↓
Implementation Plan
        ↓
Develop
        ↓
Review
        ↓
Test
        ↓
Delivery

我不希望 Requirement 一進來，AI 就直接開始 Coding，而是先理解現有 Code、找到 Data Flow、分析影響範圍，也找出需求裡還沒釐清的地方，再決定怎麼修改

Coding 的時候也想遵守一個原則：

符合現有 Architecture，但不要為了 Architecture 而 Architecture

如果 AI 想多建立一個 Interface、UseCase、Manager 或其他 abstraction，我希望自己至少能回答：

為什麼現在需要多這一層？

AI 省下來的時間，我想拿去搞懂 Why

這也是這次挑戰另一個很重要的目標

我不打算一天學完整個 Flow、Coroutine 或 Compose，而是從每天實際碰到的 Code 裡，挑一個自己其實沒有完全理解的東西往下研究

碰到 StateFlow，就去理解為什麼它適合保存 UI State
碰到 SharedFlow，就研究它跟 StateFlow 到底差在哪
碰到 viewModelScope，就去理解它和 Coroutine、Lifecycle 之間的關係等等

AI 幫我把 Code 寫快一點，我把省下來的時間拿去搞懂為什麼

這 30 天要怎麼實驗？

主要會拿我自己過去寫的時間管理 App 當實驗場

它原本使用 XML、Fragment Navigation、Flow 和 Coroutine，我不打算為了這次挑戰全部打掉重練，而是保留原本的程式碼，再加入一小塊 Compose / MVI 的新功能

這樣也剛好可以看看，同一套 AI Workflow 面對不同時期、不同 Architecture 的 Code，到底還有沒有用

工作上遇到的問題也可能會成為題目來源，不過只會留下「問題類型」，再回到自己的 Project 設計不同的案例，不使用公司的 Code、API、設計或業務邏輯

如果有機會，也想找一個自己完全不熟悉的 Open Source Android Project，看看這套方法換到不同 Codebase 之後還能不能用

30 天後，我希望留下什麼？

我希望最後不只是 30 篇文章

除了自己的 Android Project 多一小塊 Compose / MVI 實作之外，也希望可以慢慢整理出一套真的會拿來用的 Android AI Development Workflow，例如：

analyze-change
develop-feature
review-change
explain-why

這些不會是 Day 1 就決定好的答案，而是接下來 30 天實際使用、修改、驗證之後留下來的結果

而我最希望留下的其實還是：

比 Day 1 更理解自己正在寫什麼的 Android Engineer

現在的我還不知道這套 Workflow 最後會長成什麼樣子，也不知道換到不同 Codebase 後到底還剩多少價值，但如果 AI 已經可以幫我省下很多原本花在寫 Code 上的時間，那我想把這些時間拿去多問一點：

為什麼這段 Code 應該這樣寫？

30 天後，希望自己不只是更會叫 AI 寫 Code，也更有能力判斷它寫出來的東西到底好不好

下一集見 :)